Cloud computing has become a hotspot in information industry in recent years. In the general background of cloud computing, Software-as-a-Service (SaaS), Infrastructure-as-a-Service (Iaas) and Platform-as-a-Service (PaaS) have become hotspot services, and there is a trend towards Everything-as-a-Service (XaaS). Under the influence of the thought of XaaS and in the light of the development thought of electric systems (users use power only but not construct their own power plants for power supply), Network-as-a-Service (NaaS) may be provided for small and medium-sized enterprises or even for large-scale enterprises, that is, the network of each enterprise user is provided by a service provider, rather than that the service provider provides Internet network connection for the enterprise user network and the user himself constructs his own internal network/Intranet, the IT system and other related service systems. In this way, on one hand, new business growth can be brought for the service providers, and on the other hand, for enterprise users, especially for small and medium-sized enterprise users, benefits are gained such as the achievement of a standard network security and obtaining of the network at less expenditure.
Further, with the deployment of IaaS, network services need to be provided for a great number of users in a data center network, that is, it is needed to provide separated networks for a great many users in a data center network. Under the current technical conditions, the networks are separated via a Virtual Local Area Network (VLAN) or a Layer 3/Layer 2 Virtual Private Network (L3/L2 VPN).
However, as most of existing data center networks have a big L2 access network and related L3 networks, an L3/L2 VPN is not much applicable mainly for the sake of the necessity to deploy new network function entities (PE) in the network, and as the number of VLANs is limited not more than 4096, generally, VLAN cannot meet the demand for service provision by a large data center. Thus, at present, based on an idea of constructing and isolating virtual networks using different tunnel technologies on the existing networks, virtual networks of a data center are realized by overlay networks, which, meanwhile, addresses the problem of extendibility. Specifically, as shown in FIG. 1, in a data center network, overlaid tunnels are encapsulated by introducing End Point of Virtual Tunnel (VTEP), thereby realizing virtual networks for a plurality of users (that is, a plurality of tenants). The typical technologies used include Virtual Extensible Local Area Network (VXLAN), Network Virtualization Using Generic Routing Encapsulation (NVGRE) and so on. In view of the realization of Network-as-a Service, the connection condition between an L2 network and an L3 network should be paid attention to, and the description is given here based on the technical background of VXLAN. That is, a tunnel technology is introduced into an L3 network to encapsulate, transmit and connect an L2 network via the L3 network, specifically, VTEP may be a Hypervisor, an access switch or a router, wherein the Hypervisor may specifically be a software system supporting the running of a virtual machine on a physical computer.
The specific realization flow of a virtual network, as shown in FIG. 2, includes: connecting a Virtual Machine (VM) with an access switch via a vSwitch in a Hypervisor, that is, connecting the VM with the access switch via a vNIC and a vSwitch. To separate traffics of different VMs in the same physical machine, a VLAN technology is needed if the VMs belong to different user networks. As shown in FIG. 2, Personal Computers may not be virtualized as VMs, but directly access/constitute a VN instead.
Step 201: VMs are connected with a VTEP and allocated to different VNs.
In this step, different VNs are identified by network names, wherein the network names are employed for being used by operators easily and identifying VNs conveniently, further, the network names can be mapped to network identifiers for network transmission, and usually, the identifiers use a 24-bit field, that is, up to 16 million VN can be identified. It should be appreciated that the field of other bits, for example, 32 bits, can be used to provide a wider virtual network range.
Step 202: The VTEP generates corresponding VN forwarding table entry for a specific VM;
specifically, the VTEP acquires the correspondence relationship between the Medium/Media Access Control (MAC) address and/or Internet Protocol (IP) address of the VM and the IP address of the VTEP according to preset information and generates a VN forwarding table.
Step 203: The VTEP may send the correspondence relationship between the VM MAC and the IP address of the VTEP to all related VTEPs in the virtual network via MP-BGP or extended protocols of MP-BGP;
here, the VN forwarding tables also may be synchronized using an approach similar to the conventional learning mechanism of the data plane of an Ethernet switch, without using MP-BGP.
Step 204: All the related VTEPs generate corresponding VN forwarding table entry for the specific VM.
Step 205: When there is a packet needing to be forwarded, the VTEP looks up the VN forwarding table for the entry corresponding to the VM for information such as the destination address of the message and performs tunnel encapsulation;
specifically, the VTEP looks up the VN forwarding table entry corresponding to the VM for the destination IP address and the MAC address of the correspondent VTEP according to the destination address of the packet and performs tunnel encapsulation, that is, performs IP encapsulation on an L2 packet/frame, and forwards the encapsulated packet via an L3 network.
It should be further noted that as the VTEP may be in the L2 network, L2 encapsulation may be further performed for the encapsulated IP packet.
Step 206: The VTEP sends the packet to the correspondent VTEP.
Step 207: After receiving the related virtual network encapsulated packet, the correspondent VTEP decapsulates the received packet to obtain the L2 packet and forwards the L2 packet to the correspondent PC/VM;
it should be appreciated that the returning of a packet from the correspondent PC/VM is similar to the foregoing flow and is therefore not described here repeatedly.
The foregoing flow is similar to the conventional network service deployment of a Multi-Protocol Label Switching (MPLS) Virtual Private Network (VPN). From the point of view of protocol, with a manually configured VTEP in combination with the protocols used between VTEPs or a learning mechanism of a data plane, a service can be deployed. However, it is a huge amount of work to manually configure VNs when there is a great many of PC servers, for example, when there is a data center which has hundreds of thousands of computers each of which further may create dozens of virtual machines; furthermore, the dynamic joining or departing of a VM to or from a VN complicates the service deployment of the VN.